…re-time semantic

C++ and Python compute getTimestampSeconds() as (receive - latency)
while Java reads metadata.captureTimestampMicros directly. The C++
path additionally pre-subtracts latency in PhotonCamera before
SetReceiveTimestamp, so GetTimestamp() subtracts latency a second
time — making every C++ vision timestamp off by ~one full processing
latency.

This change has all three ports read metadata.captureTimestampMicros
directly. Two properties of that field make this safe:

  1. It is in the Time Sync Server's nt::Now timebase (FPGA-relative
     on a real robot). At
     photon-core/src/main/java/org/photonvision/common/dataflow/networktables/NTDataPublisher.java:200-211
     the coprocessor reads getImageCaptureTimestampNanos(), adds the
     TimeSyncClient offset, and writes the result to the wire — with
     the in-line comment "Transform the metadata timestamps from the
     local wpi::nt::Now timebase to the Time Sync Server's timebase".

  2. Latency compensation is already baked in by the coprocessor.
     photon-core/src/main/java/org/photonvision/vision/pipeline/CVPipeline.java:82
     stamps frame.timestampNanos onto the result AFTER process()
     returns, so the value is the moment of capture, not publish.
     frame.timestampNanos itself is shutter-open time, set by the
     driver at
     photon-core/src/main/java/org/photonvision/vision/frame/provider/LibcameraGpuFrameProvider.java:95-101
     before any processing happens. The direction is confirmed by
     photon-core/src/main/java/org/photonvision/vision/pipeline/result/CVPipelineResult.java:112-114
     where getLatencyMillis() returns (wpiNanoTime() - capture) — a
     positive value, meaning capture precedes the latency reading.

ntReceiveTimestamp keeps its documented meaning (FPGA time bytes
arrived at robot code) for diagnostics. PhotonCamera no longer
pre-subtracts latency before SetReceiveTimestamp.

C++ tests previously relied on the (receive - 0_latency) projection
through GetTimestamp; updated to set captureTimestampMicros in
metadata directly, matching the Java test idiom.

…nit wrap

wpiformat (clang-format with the WPILib config) reflowed two
PhotonPipelineResult brace-initializers in this file. The CI Lint and
Format job rejected the prior wrap in both
ClosestToCameraHeightReturnsEmptyForNoFiducialTargets and
ConstrainedPnpOneTag; this commit applies the formatter's chosen split.

Pure whitespace; no semantic change.

…thon

Responds to mcm001's review on PR PhotonVision#2496: with getTimestampSeconds()
now reading metadata.captureTimestampMicros directly, the
ntReceiveTimestamp fallback has no remaining consumers — across the
entire repo, the field is written but never read. Java has never had
the analog at all. Deleting it brings the three ports into alignment
with Java as the reference.

C++ (photon-targeting + photon-lib):
- Remove ntReceiveTimestamp field, SetReceiveTimestamp setter, and
  the five bespoke copy/move/operator= members on PhotonPipelineResult
  whose sole purpose was propagating that field across the proto-
  generated Base. Defaulted special members are equivalent now that
  the only "extra" subclass field is gone.
- Drop both SetReceiveTimestamp call sites in PhotonCamera.cpp, the
  now-unused 'now' local in GetLatestResult, and the
  <wpi/system/RobotController.hpp> include.
- Strip 14 SetReceiveTimestamp lines from PhotonPoseEstimatorTest.cpp.
  Every test still sets metadata.captureTimestampMicros directly, so
  GetTimestamp() returns the expected value via the metadata path.
- Drop the CopyResult test that existed solely to verify the bespoke
  copy ctor propagated ntReceiveTimestamp; defaulted base copy is
  exercised by every other test in the suite.

Python (photon-lib/py):
- Remove ntReceiveTimestampMicros field from the PhotonPipelineResult
  dataclass and the three assignments (two in PhotonCamera, one in
  the sim). The sim's "+10" microsecond offset was decorative; the
  value was never observed.
- Drop the now-unused RobotController import in photonCamera.py and
  the _receiveLatencyMicros / receiveTimestampMicros() helper on
  PipelineTimestamps in test/testUtil.py.

…thon

…docs

The getCaptureTimestampMicros / getPublishTimestampMicros Javadocs
claim "coprocessor's time base", but NTDataPublisher applies the
TimeSyncClient offset to both values before publishing — the
on-wire value is in the Time Sync Server's nt::Now timebase, not
the coprocessor's local clock.

The field-level comment at PhotonPipelineMetadata.java:25-26 already
states the correct timebase ("wpi::nt::Now on the time sync server").
This commit aligns the getter Javadocs (which users see in IDE
autocomplete and online API docs) with that truth.

The Python per-field comment carried the same misleading prose;
updated to match.

No code or behavior change.